Typical integrated fast packet networks carry at least three classes of traffic: continuous bit-stream oriented (CBO), voice, and data. FIG. 1A-C illustrates the bandwidth characteristics and requirements of these differing traffic types, and their attributes are summarized as follows.
CBO: Packets from individual sources are fairly well-behaved and arrive at the internodal trunk queues more or less periodically. The peak rate (R.sub.peak) of multiplexed CBO sources is the same as the average rate (R.sub.avg), and the trunk bandwidth required (R.sub.reqd) is somewhat larger to keep the queueing delays small. Since R.sub.peak &lt;R.sub.reqd, no statistical gain is obtained in this case. CBO streams are sensitive to severe fluctuations in queueing delay and to packet losses since both of these cause a loss in synchronization at the receiver. Packets from CBO sources with large packetization times have large delays when multiplexed together as opposed to packets from sources with small packetization times. When multiplexed together, the delays are dominated by the large packetization time sources.
Packet Voice (with speech activity detection): The rate of multiplexed voice depends on the number of sources simultaneously in talk spurt and fluctuates between the maximum rate (R.sub.peak) and zero. The average rate (R.sub.avg) is less than half of R.sub.peak (for conversational speech). The required rate (R.sub.reqd) can be made to lie in between these two rates (rather than being made equal to R.sub.peak), making statistical gain (i.e., R.sub.peak /R.sub.reqd) possible. R.sub.reqd is chosen to keep the maximum delay and the packet loss rate under the given limits (a small loss is acceptable since degradation in voice quality can remain within acceptable limits).
Packets with excessive delays (typically a few hundred millisecs) are also dropped at the destination based on an end-to-end delay limit, since voice is delay sensitive. This type of dropping results in (with a high probability) several packets being consecutively lost from the same voice call and degrades the fidelity of the received voice signal seriously.
Framed Data: This type of traffic can have large fluctuations in the rate and in the difference between R.sub.peak and R.sub.avg. R.sub.reqd is chosen to keep the end-to-end average frame delays acceptably small. Since the loss of a single fast packet results in of an entire frame, it is not desirable to drop packets. However, since data traffic is bursty in nature, the loss of packets due to the non-availability of buffers cannot be prevented. Additionally, data traffic from different sources have differing quality of service (QOS) requirements; e.g. interactive traffic, is relatively delay sensitive, whereas file transfers are less so.
Integrated networks considered here rely on fast packet technology to transport such packets between end systems. Before the flow of packets between the end systems begins, a connection (or virtual circuit) is established between them. This connection determines the path (i.e., the nodes and internodal trunks) that the fast packets will follow from end to end. FIG. 2 depicts a switch typically used at an intermediate node, that receives fast packets from one or more input trunks and switches them to one or more output trunks.
Packets coming in on an internodal trunk from each connection have a unique field in the header, called the Logical Channel Number (LCN), that corresponds to a logical channel on that trunk (see FIG. 3A). At the time of the establishment of the connection, a table is updated (at each node) that contains entries for the output Port number, the Queue ID (QID) of the output queue, and the new LCN. The LCN of each incoming packet is examined and this address is translated (by access to the table) to the output Port number, QID (for an output queue), and the new LCN for the next internodal trunk (see FIG. 3B).
The packets from the various output queues are transmitted (or discarded) in an order determined by the particular queueing discipline used in the network. (Though this invention is described with this environment in mind, the queueing discipline structure and methods described herein are applicable to a broad class of connection oriented or connection-less networks and are not limited to an implementation using LCNs and table lookups).
For example, one technique for queueing packets for transmission on an internodal trunk uses a first-in-first-out (FIFO) queue. Multiplexed voice and data traffic, however, experience overload periods when the instantaneous rate of packets entering a trunk becomes larger than R.sub.reqd (which corresponds to the trunk bandwidth allocated to that traffic). The overload periods for voice can be expected to last from 10 ms to 1000 ms. For data, the periods can last from a few ms to several seconds. CBO sources are sensitive to fluctuations in queueing delays that vary between 1 ms and 32 ms per hop in typical T1 networks (when CBO sources alone are multiplexed into the same queue). Clearly, long overload periods for voice and data caused by a simple FIFO queue could make CBO queueing delay fluctuations as long as the overload periods, and would cause the end-to-end delays to be unacceptable high, since a longer smoothing delay would be required at the destination to prevent gaps from occurring during the bit-stream. Similarly, when data goes into overload, it dominates the trunk bandwidth and causes voice quality to deteriorate (since it would cause voice packets to be delayed or dropped). These clearly undersirable characteristics occur when all the traffic enters one queue.
Another approach uses pure Head Of Line Priority (HOLP) to give data priority over voice. However, HOLP does not solve the problem of data and voice queues affecting the QOS of each other and of CBO when they go into overload. In addition, CBO, voice, and data queues have typical busy periods (1 ms to 32 ms for CBO, 10 ms to 1 sec for voice, and up to a few secs for data) that are not only different but also large enough to cause one type of traffic to dominate the link bandwidth for relatively large amounts of time. For example, if CBO is given highest priority, even though it never goes into overload, a long busy period (say 32 ms) could affect the quality of the voice connections because voice packets could be blocked for 32 ms at that hop. If HOLP was used and voice was given either the highest or second highest priority (it cannot be given the lowest as it is delay sensitive), the voice queue would just take up more bandwidth when it went into overload. Instead of the voice queue growing and losing packets (via a discard mechanism), it would (unfairly) affect the quality of service of the lower priority queues.
Movable boundary schemes for multiplexing two traffic types, voice and data, have also been proposed. In such schemes, the multiplex structure consists of frames that are made of transmission time slots. At the start of the frame, there are S time slots reserved for voice and the next N slots for data. At the start of the frame, if there are S or more voice packets awaiting transmission, they are loaded into the S time slots and data packets are loaded into the remaining N slots (if there are more than N they are queued). If there are less than S voice packets at the start of the frame, data packets are permitted to use the extra timeslots (thus leading to the term "movable boundary"). Such methods neither consider priorities within a class of traffic nor do they propose an efficient discard mechanism.
In another scheme, timers are used to implement the movable boundary between voice and data queues and a block dropping scheme that assumes embedded coding is used for voice. One approach in particular proposes four classes of traffic (with HOLP within each class if required), along with a discard mechanism for the class corresponding to voice traffic. The movable boundary scheme is implemented by limiting the number of packets transmitted in succession from any traffic class.
Queueing structures for virtual circuit (VC) based networks have also been proposed. The queueing disciplines described in these methods separates the VCs into priority classes and uses round-robin scheduling between VC's. This discipline is more appropriate for conventional networks that use link-by-link flow control (as versus fast packet networks that use end-to-end flow control), since the flow into a queue can be tightly controlled. In addition, this discipline does not address the problem of integrating different traffic types to match quality of service requirements and are geared instead to providing fair service to VCs by serving them in a round-robin order before they are multiplexed. This would not work in the environment of the invention since CBO and voice sources cannot be flow controlled and the HOLP discipline between CBO, voice, and data is insufficient (as described earlier).
Packet discarding has also been proposed to relieve congestion in an integrated voice/data network. In such mechanisms, new incoming packets are discarded if the queues becomes excessive (i.e., filled). A disadvantage of this mechanism is that it discards packets without considering the importance of the packet. Using speech coding and speech activity detection, some of the packets contain particularly important information. To reduce the impact of this sort of discarding, a selective packet discarding technique has been proposed. Only the packets considered to be less important for voice waveform reconstruction are discarded in face of congestion, which is identified by the queue depth or the number of calls in talk spurt (i.e., packet arrival rate). In the selective packet discarding, packets are classified into two discard priorities. Both schemes described above use only a single threshold for the indication of congestion.
Pursuant to another packet discarding mechanism, if an output queue of an internodal trunk is full, an incoming packet of the queue is dropped. If the queue is not full but the queue depth exceeds a given threshold and the incoming packet is marked droppable, the packet is also dropped. Otherwise, the packet is placed in the queue waiting for transmission. An alternative for dropping marked packets, referred to as "output dropping" has also been suggested, in which all incoming packets may be placed in the queue if the queue is not full. When a marked packet moves up to the head of the queue and is ready for transmission, the threshold is checked, and the packet will be dropped or transmitted accordingly.
None of the above described methodologies provide fully satisfactory performance, particularly when applied in an integrated fast packet network that supports transmission of varying traffic types.